Новые лабораторные работы по VMware vSphere 6 - попробуйте новую версию платформы без установки.

Как почти все из вас знают, компания VMware совсем недавно анонсировала новую версию платформы виртуализации VMware vSphere 6 и другие продукты серверной линейки (наша последняя статья об этом тут). Пока сам продукт недоступен для загрузки в релизной версии, но компания VMware на днях предоставила возможность попробовать его вживую в виде лабораторных работ - VMware Hands-On Labs (HoL).

В рамках лабы вам развертывают виртуальную машину, с которой вы работаете прямо в браузере:

На данный момент доступно 4 новых лабораторных работы:

1. HOL-SDC-1408 - What’s New with Virtual SAN 6.

Эта лаба вводит начинающих в суть темы отказоустойчивых кластеров Virtual SAN и позволяет понять основные преимущества технологии на практике, никакого булшита. Модули лабы:

• Virtual SAN Setup and Enable
• Virtual SAN with vMotion, Storage vMotion and HA Interoperability
• Virtual SAN Storage Level Agility
• Useful CLI Commands
• Virtual SAN Monitoring
• Virtual SAN Troubleshooting

Время на прохождение: 4-5 часов.

2. HOL-SDC-1410 - What's New with vSphere 6.

Данная лабораторная работа расскажет о новых возможностях платформы VMware vSphere 6 в плане сервисов управления и мониторинга. Доступно три модуля:

• Introduction to Management with vCenter Server
• Introduction to vSOM Networking And Security
• Introduction to vSOM Storage

Время на прохождение: 3 часа.

3. HOL-SDC-1428 - VMware EVO:RAIL Introduction.

В этой небольшой лабораторной работе вам расскажут про технологию EVO:RAIL, которая представляет собой стандартизованный строительный блок виртуальной инфраструктуры для небольших компаний. С технической точки зрения EVO:RAIL - это двухюнитовый блок, представляющий собой 4-узловую структуру на базе архитектуры "microserver", которая сочетает в себе 4 полноценных микросервера в 2-юнитовой корзине.

Эта лаба состоит из двух модулей:

• Exploring EVO:RAIL Configuration
• Exploring EVO:RAIL Management

Время на прохождение: 1 час.

4. HOL-MBL-1452 - Horizon 6 with View Use Cases.

Эта лабораторная работа, посвященная возможным вариантам применения VMware Horizon 6, была доступна и ранее. Но теперь в нее добавили модуль о технологии AppVolumes, про которую мы писали вот тут (ранее это называлось CloudVolumes).

Модули лабораторной работы:

• Build and Operate the Mobile Secure Workplace
• Build and Operate the Call Center Desktop
• Build and Operate the Branch Office Desktop
• Take a Guided Tour of vCOPS for View
• Understanding use cases for Application Remoting
• Understanding use cases for Cloud Pod Architecture
• Mirage-Controlled View Static Desktops
• Guided Tour of AppVolumes

Время на прохождение: 5-8 часов (то есть на всю лабу лучше выделить целый день).

В течение пары недель компания VMware обещает выложить еще несколько лабораторных работ, посвященных VMware vSphere 6 и другим продуктам и технологиям обновленной серверной линейки, о которых мы вам обязательно расскажем. Можно также следить за обновлениями в твиттер-аккаунте VMware HoL.

Совсем недавно компания VMware анонсировала новую версию платформы виртуализации VMware vSphere 6.0, а также обновленные версии продуктов своей серверной линейки. Напомним наши статьи об этом:

• Впервые на арене - компания VMware открыла публичную бету новой версии VMware vSphere 6.0
• Новые возможности VMware vSphere 6 - новости с VMworld 2014
• Новая архитектура сервисов управления VMware vCenter в VMware vSphere 6
• Новые возможности VMware Fault Tolerance в VMware vSphere 6.0
• Что нового в VMware Virtual SAN 6.0 из состава vSphere 6.0

Вместе с vSphere 6.0 было также объявлено и об обновлении до версии 6.0 виртуального модуля VMware vCenter Server Appliance (vCSA), построенного на базе ОС Suse Linux (SLES 11 SP3), в котором соответствующим образом настроены параметры безопасности и необходимые сервисы vCenter.

Кстати, напомним наши статьи о vCenter Server Appliance:

• Почему виртуальный модуль VMware vCenter Server Appliance (vCSA) еще не годится для производственной среды
• Аспекты применения VMware vCenter Server Virtual Appliance в vSphere 5
• Что выбрать - установку VMware vCenter в виртуальной машине или уже готовый модуль vCenter Server Appliance (vCSA)

Ну а ниже мы расскажем, что нового появилось в vCSA 6.0.

1. Новая установка.

Теперь для развертывания vCSA понадобится ISO-образ, который можно загрузить прямо из веб-клиента vSphere:

Сам виртуальный модуль развертывается из OVF-пакета, также потребуется установить Client Integration Plug-in.

2. Типы развертывания.

С точки зрения самого vCenter появляется новый сервис Platform Services Controller (PSC), который заменяет существующие сервисы Single Sign-On (напомним, что они уже были переписаны в версии SSO 5.5). Если ранее SSO был частью vSphere и обновлялся только вместе с платформой, то теперь PSC может быть обновлен отдельно (например, если появились новые источники аутентификации или были исправлены ошибки), что очень удобно.

На картинке ниже Platform Services Controller может быть выделен для каждого сервиса vCenter, но также и несколько сервисов vCenter могут использовать один выделенный PSC (этот режим называется External PSC).

Более подробно мы писали об этом тут.

3. Скриптовая установка.

Помимо обычной установки из GUI с помощью мастера, vCSA можно развернуть в режиме скриптовой установки. Для этого в папке vCSA-CLI-Installer есть пять различных файлов сценариев, которые подходят под различные варианты развертывания.

4. "Размер" модуля.

При развертывании теперь просят указать "размер" виртуального модуля (один из четырех видов), от которого зависит его конфигурация и максимальное число хостов и ВМ:

5. Поддержка большинства функций vCenter для Windows.

Теперь vCSA больше похож на обычный vCenter Server для Windows. Действительно, посмотрите на таблицу:

Также vCSA поддерживает следующие возможности:

• Полная поддержка Hardware version 11.
• Встроенная и настроенная СУБД vPostgres (в качестве внешней базы также поддерживается Oracle).
• Нативная репликация вместо Microsoft ADAM.
• Репликация политик и тэгов в Linked Mode.
• Возможность накатывания обновлений (Product & Security) через Patch Portal.

Что не поддерживается:

• Не реализована поддержка VMware Update Manager (по прежнему, надо ставить на винду).
• Нет поддержки Microsoft SQL Server.
• Нет средств миграции SQL Server на vPostgres.

6. Три способа доступа к консоли виртуального модуля.

Теперь получить доступ к vCSA можно тремя способами:

• Обычный, через vSphere Web Client.
• Доступ через Appliance Shell - в этом режиме мы переходим в консоль по SSH или через интерфейс DCUI при нажатии Alt+F1.
• Через DCUI - в DCUI можно получить доступ прямо из Web Client на вкладке Summary (тадо нажать на само изображение консоли).

Прямой доступ по порту через веб-браузер больше не поддерживается.

Вот тут можно посмотреть на весь процесс установки vCSA. Кстати, говорят загружается виртуальный модуль со всеми поднятыми сервисами достаточно долго - около 8 минут.

Как вы знаете, недавно компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, и мы уже писали о технологии непрерывной доступности VMware Fault Tolerance 6.0.

Сегодня мы хотим рассказать об отказоустойчивых кластерах VMware Virtual SAN 6.0, для которых версия программного обеспечения продвинулась с 1.0 сразу до 6.0 (поэтому пользователи, все же, не должны заблуждаться насчет зрелости продукта - это его вторая версия).

Итак, что нового появилось в VMware Virtual SAN 6.0:

1. Поддержка архитектуры All Flash для создания кластера хранилищ.

Теперь доступны два варианта развертывания VSAN:

• Hybrid – Virtual SAN, как и раньше, использует SSD-диски для кэширования, а для хранения ВМ используются обычные HDD-диски. Максимально возможные конфигурации этой архитектуры стали выше (например, стало 64 хоста в кластере).
• All Flash – Virtual SAN использует имеющиеся Flash-накопители как для кэширования, так для хранения ВМ.

Отличия между данными архитектурами:

В конфигурации All Flash девайсы, ответственные за кэширование, будут производить только кэширование записи и не будут делать кэширование на чтение (это очевидно почему). В гибридной конфигурации, как и раньше, 30% емкости SSD-кэшей используется для Write Buffer, а 70% - для кэша на чтение.

В целом, утверждается, что решение Virtual SAN теперь готово к полноценной промышленной эксплуатации.

2. Возможность High Density Direct Attached Storage (HDDAS).

Теперь кластеры Virtual SAN удобно использовать в окружениях с блейд-системами. Для них поддерживаются как SDD, так и HDD-устройства, включая flash-хранилища блейд-серверов.

Если раньше блейд-системы не очень подходили для организации кластеров ввиду физических ограничений по локальным хранилищам, то теперь это вполне подходящий вариант использования для корпоративной инфраструктуры. Поддержка устройств будет строго контролироваться и постоянно обновляться в VMware HCL.

3. Новая файловая система и формат On-Disk.

Virtual SAN в VMware vSphere 5.5 использовал модифицированный формат файловой системы VMFS с измененным механизмом блокировок, которая называлась VMFS-L. Теперь же в VSAN 6.0 используется файловая система VSAN FS, специально предназначенная для кластеров хранилищ.

Старый формат VMFS-L поддерживается и в новой версии, но VMware предлагает провести миграцию хранилищ, тем более что это делается без простоя сервисов.

4. Функции Proactive Rebalance.

В Virtual SAN 6.0 появилась возможность ребаланса объектов по виртуальным дискам в случае, если подключается новый узел vSphere или если диски заполнены на 80% и более. Делается это через Ruby Console.

5. VSAN Fault Domains (группы отказа).

Теперь в VSAN можно определять домены отказа, то есть группы хостов у которых может произойти одновременный сбой (например, отказ питания на стойке), чтобы все их объекты были задублированы в других доменах:

Теперь реплики объектов происходят не на уровне хостов, а на уровне Fault Domains (в данном случае инфраструктура хранения переживет отказ одной стойки):

6. Новые функции для дисков (Serviceability Functions).

• Light LED on failures – включение LED-индикатора при отказе.
• Turn on disk LED manually - включение LED-индикатора вручную для диска, чтобы его можно было найти на массиве.
• Marking a disk as local – если диск не обнаружился как локальный, его можно пометить вручную из GUI.
• Marking a disk as SSD - теперь эта опция есть в GUI, нужна если диск автоматически не распознается как SSD.

7. Улучшения сетевого взаимодействия.

Теперь Virtual SAN 6 поддерживает конфигурации на уровне Layer 3. Кроме того, теперь доступна конфигурация с Jumbo Frames. Ну и добавлена поддержка возможностей vDS и Network IO Control (NetIOC).

8. Новый тип виртуального диска VMDK - vsanSparse.

Ранее использовались стандартные Redo-диски, но они не были приспособлены под кэширование и другие функции VSAN FS, поэтому сделали новый тип диска vsanSparse.

9. Улучшенные функции Disk/Disk Group Evacuation.

Возможность эвакуации данных с отдельного диска или группы перед тем, как вы его хотите вывести из эксплуатации физически. Ранее приходилось переводить весь хост в Maintenance Mode, чтобы было очень неудобно при поломке лишь одного диска.

10. Новое представление Resynchronization Dashboard.

Это представление показывает статус объектов, которые по тем или иным причинам находятся в состоянии ресинхронизации. Также показывается примерное время окончании синхронизации:

11. Новые службы 3rd Party File Services.

Сторонние вендоры теперь могут надстраивать свои решения над VMware Virtual SAN. Например, мы писали о таком решении совсем недавно - это NexentaConnect.

12. Полноценная поддержка командлетов PowerCLI.

Ранее интерфейс PowerCLI поддерживался неофициально, теперь же командлеты задокументированы и поддерживаются:

13. Службы мониторинга жизнедеятельности (VSAN Health Services).

Теперь для компонентов Virtual SAN доступна информация об их состоянии:

14. Storage Consumption Models.

Возможность визуализовать использование ресурсов хранения Virtual SAN 6.0 при создании или изменении VM Storage Policy.

О доступности VMware Virtual SAN 6.0 будет объявлено отдельно.

Как вы знаете, вчера компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, но нас больше всего заинтересовала технология непрерывной доступности VMware Fault Tolerance.

Ранее никто не воспринимал технологию Fault Tolerance всерьез, поскольку она была доступна только для виртуальных машин с одним vCPU, а такие машины, как правило, не делаются для бизнес-критичных приложений, для которых, собственно, технология Fault Tolerance и создавалась.

Теперь VMware Fault Tolerance в VMware vSphere 6.0 полноценно доступна для виртуальных машин с четырьмя vCPU и 64 ГБ оперативной памяти. И все это поддерживается в производственной среде.

Какие преимущества дает VMware FT в vSphere 6.0:

• Непрерывная доступность и полное сохранение данных ВМ в случае отказа хоста ESXi.
• При отказе не разрывается TCP-соединение.
• Срабатывание Fault Tolerance полностью прозрачно для гостевой системы.
• При сбое хоста происходит переключение на новую первичную ВМ, при этом на другом хосте автоматически поднимается новая резервная ВМ.

Что нового в Fault Tolerance 6.0:

• Теперь технология непрерывной доступности VMware Fault Tolerance поддерживает виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
• Fast Check-Pointing - новая технология, предназначенная для поддержания исходного и резервного узла в синхронном состоянии, пришедшая на смену технологии "Record-Replay".
• Поддержка технологии горячей миграции как для Primary, так и для Secondary-узла.
• Возможность резервного копирования виртуальных машин, защищенных с помощью FT, технологией vStorage APIs for Data Protection. То есть, для таких ВМ теперь работет Veeam Backup and Replication.
• FT в vSphere 6.0 поддерживает новые типы дисков, такие как EZT, Thick или Thin Provisioned. Для vSphere 5.5 и более ранних поддерживаются только диски типа Eager Zeroed Thick.
• Возможность создания снапшотов виртуальных машин, защищенных FT.
• Новая версия FT поддерживает отдельные копии файлов ВМ (.vmx и .vmdk) для каждой машины, чтобы защитить машину не только от сбоев хоста, но и от сбоев хранилища, которые могут произойти одновременно со сбоем хоста. Файлы Primary и Secondary VM могут быть на разных виртуальных хранилищах.

Но по-прежнему, для Fault Tolerance остаются следующие ограничения:

• На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
• Обязательно потребуется адаптер 10 Gb. Его можно разделять между различными типами трафика средствами NetIOC.
• Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
• Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
• Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.

Как и раньше, технология VMware HA полностью поддерживается:

Для наглядности есть вот такая табличка, описывающая отличия от предыдущей версии FT:

Надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.

Ну и помните, что VMware Fault Tolerance на защитит от сбоя на уровне приложения - если он произойдет в основной ВМ, то будет и в резервной ВМ, поскольку машины синхронизированы на уровне исполнения инструкций в процессорах.

Некоторое время назад мы писали про серьезный баг в механизме Changed Block Tracking (CBT), который используют практически все средства для резервного копирования виртуальных машин на уровне хоста ESXi, например, Veeam Backup and Replication.

Суть бага заключалась в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.

Проблема была обнаружена в начале ноября прошлого года, но только сейчас компания VMware пофиксила этот баг. Описание проблемы и решений можно найти в KB 2090639.

Патчи можно скачать по следующим ссылкам:

• ESXi 5.0 Patch 10 - VMware ESXi 5.0, Patch Release ESXi500-201412001 (2088715). Для загрузки используйте Patch Portal.
• ESXi 5.1 Update 3 - VMware ESXi 5.1 Update 3 Release Notes. Для загрузки используйте раздел VMware Downloads.
• ESXi 5.5 Patch 4 - VMware ESXi 5.5, Patch Release ESXi550-201501001 (2099265). Для загрузки используйте Patch Portal.

Zip-файлы патчей можно импортировать через VMware Update Manager:

/p>

Напомним, что для решения проблемы без патчей, надо "перещелкнуть" Changed Block Tracking на хосте ESXi (как это сделать - тут и в KB). Старые бэкапы, понятное дело, останутся невалидными. Следующий бэкап после повторного включения CBT всегда будет полным.

Интересно, что для VMware vSphere 4.x никаких патчей на эту тему выпущено не было (Currently, there is no resolution for ESXi 4.x.).

Отметим также, что компания Veeam уже давно выпустила решение этой проблемы. Пользователям Veeam Backup and Replication 8 вообще ничего делать не нужно - там эта проблема уже решена.

Как вы знаете, после запуска виртуальной машины на платформе VMware vSphere, в папке с машиной создается файл *.vswp, который предназначен для свопирования памяти ВМ в критической ситуации. Если у машины проявляется нехватка памяти на хосте VMware ESXi, и она не получает ее через механизм Memory Ballooning, то страницы памяти начинают сбрасываться в этот vswp-файл. Это самая плохая ситуация, так как структурная организация этого файла и то, как понимает своп операционная система, две большие разницы, а значит скорость работы существенно замедляется не только из-за того, что работа идет с диском вместо RAM, но еще и уходит время на поиск нужных страниц.

Соответственно, если у машины 4 ГБ оперативной памяти, то размер vswp-файла также 4 ГБ:

Если мы меняем Memory Reservation для виртуальной машины, то ее файл подкачки уменьшается на величину этого резерва - так как физическая память закрепляется за машиной и не возникнет условий, когда эту часть потребуется свопировать.

Но если сделать Memory Reservation для работающей ВМ (в данном случае 2 ГБ), то размер файла подкачки останется прежним:

Для того, чтобы vswp-файл уменьшился на величину Memory Reservation, надо перезагрузить ВМ - тогда он станет размером 2 ГБ:

Напомним, что у выключенной машины vswp-файла нет.

Но что если у включенной машины убрать (или изменить) Memory Reservation? Все просто - он автоматически увеличится до размера незарезервированной памяти ВМ. Убираем резерв в 2 ГБ и файл вырастает до 4 ГБ:

Ну и напомним формулу:

Swap (.vswp) file size = VM Configured Memory – VM reserved memory

Многие из вас, наверняка, знакомы с инициативой CoreOS (форк Chrome OS) - операционной системой на базе Linux, которая представляет собой пустую "коробку" для развертывания в ней предустановленных контейнеризованных приложений (на базе механизма Docker) и больше ничего лишнего. То есть там присутствуют только необходимые для запуска этих приложений средства.

В инициативе CoreOS принимают участие такие компании как Google, Facebook и Twitter. VMware также работает с командой CoreOS, чтобы эта система работала и поддерживалась в качестве гостевой ОС в VMware vSphere, а также обеспечивалась работоспособность пакета open-vm-tools (это аналог VMware Tools, но с открытым кодом и с меньшими возможностями).

На днях компания VMware объявила о доступности сборок CoreOS 494 и 522 для платформы VMware vSphere (как технологическое превью). Соответственно, в VMware ждут от пользователей фидбэк по результатам тестирования.

Ссылки на загрузку:

• CoreOS 494 Stable
• CoreOS 522 Stable

Для установки можно использовать стандартный ISO-образ или уже готовый VMDK-диск. В дальнейшем CoreOS будет поставляться как готовый виртуальный модуль (Virtual Appliance) в формате OVA. Например, в бета-версии сборки 577 OVA уже есть.

Инструкции по развертыванию CoreOS на VMware vSphere приведены в KB 2104303. Процесс пока еще не очень тривиален, но команда проекта работает над его упрощением. Сама же VMware работает над интеграцией проекта CoreOS в свое публичное облако VMware vCloud Air.

Чтобы начать работу с CoreOS нужно прочитать вот эти инструкции: CoreOS Quick Start. Также рекомендуем ознакомиться с VMware CoreOS community forum.

На многим из вас известном сайте VMware Labs появилось интересное мобильное приложение для смартфонов на базе Android - vMaxGuide. Оно позволяет посмотреть информацию о максимальных конфигурациях различных компонентов виртуальной инфраструктуры VMware vSphere.

На данный момент vMaxGuide предоставляет информацию о максимумах для следующих платформ:

• VMware vSphere 5.5
• VMware vSphere 5.1
• VMware vSphere 5.0

Также в сравнениях участвуют различные версии виртуального аппаратного обеспечения (Virtual Hardware). Там где максимумы могут быть достигнуты только при определенных условиях, соответствующие пункты помечены символом "*".

Инсталляция и использование vMaxGuide:

Кстати, эта штучка может быть хорошей шпаргалкой на экзамене по VMware VCP!)

Осенью мы писали о том, что компания VMware планирует отключить технологию Transparent Page Sharing (TPS) в новых релизах платформы виртуализации VMware vSphere. Напомним, что TPS - это механизм поиска и удаления дубликатов страниц памяти в целях экономии физического пространства RAM (вместо самой дублирующейся страницы хранится только ссылка на нее).

Технологию TPS было решено прекратить использовать по двум причинам:

• Использование в современных ОС больших страниц памяти (large memory pages) размером в 2 МБ делает намного менее вероятным появление дубликатов.
• Использование одной копии страницы памяти несколькими ВМ создает потенциальные проблемы безопасности.

На данный момент статус отключенности TPS по умолчанию на хостах VMware ESXi таков:

• В ESXi 5.5 U2d, запланированном на первый квартал 2015 года, TPS будет отключен.
• В ESXi 5.1 U3, выпущенном 4 декабря 2014 года, TPS уже отключен.
• В ESXi 5.0 U3d, запланированном на первый квартал 2015 года, TPS будет отключен.

Однако не стоит сбрасывать TPS со счетов - возможно, если вы используете старые ОС (Windows 2003) и инфраструктуру VDI на базе старых клиентских ОС, TPS сможет сэкономить вам какое-то количество памяти (если безопасность TPS вас не особенно заботит). Ну и напомним, что TPS отключена только для межмашинного взаимодействия и продолжает работать для внутримашинного.

Для этого в VMware сделали скрипт Host Memory Assessment Tool.ps1, который показывает количество памяти на хостах, которую можно сэкономить с помощью TPS.

Вот что он делает:

• Соединяется с vCenter и определяет хосты ESXi
• Позволяет включить SSH на хостах
• Генерирует отчет об обследовании на экономию по TPS
• Можно экспортировать результаты в CSV
• Можно снова включить SSH, если нужно

Пока скрипт позволяет указать только одну пару логин-пароль на хостах ESXi, но надеемся это будет исправлено в следующих версиях.

Здесь вот какие значения в колонках:

• Total Host Memory – объем физической памяти хоста (доступной vmkernel).
• Host Mem Saved via TPS – объем памяти, которая сэкономлена TPS.
• Host Mem Saved via TPS Zero Pages – объем памяти, которая экономится на нулевых страницах. Фактически такая экономия не актуальна для большинства случаев, так как сэкономленные нули означают, что недостатка ресурсов не наблюдается.
• Potential Host Mem Savings Lost – а вот эта экономия уже на реально используемых страницах. Объем, указанный тут, показывает сколько можно потерять, отключив TPS на хосте.
• Host Free Mem – объем свободной оперативной памяти (по данным vmkernel). Если свободной памяти меньше, чем значение в предыдущей колонке, то при отключении TPS будет своппинг.

Вот такая штука, можно проводить эксперименты (особенно полезно это будет для крупной инфраструктуры). Скрипт безопасен для памяти хостов, так как использует режим доступа к памяти только для чтения.

После запуска скрипта вам может потребоваться отключить или включить Transparent Page Sharing на хосте ESXi. В этом случае вам пригодится KB 2097593.

Как знают многие администраторы VMware vSphere, есть такое удобное средство vSphere Management Assistant (vMA), которое представляет собой виртуальный модуль (готовую виртуальную машину), средствами которой очень удобно управлять скриптами, исполняемыми на нескольких хостах VMware ESXi через интерфейс ESXCLI или Perl.

При выполнении различных сценариев на Linux-машине vMA иногда требуется создать задачу планировщика (крон-таску), чтобы запустить скрипт в назначенное время. Ниже мы опишем, как это нужно делать.

1. Чтобы запускать скрипты без аутентификации, нужно добавить хосты ESXi в vi-fastpass. Вы можете добавить только хосты ESXi, либо хост vCenter Server (или всех их). Используйте команду vifp addserver в интерактивном режиме (конфигурация сохраняется при перезагрузках):

vi-admin@vma:~> vifp addserver esx1.virten.local --username root --password 'vmware'
vi-admin@vma:~> vifp addserver esx2.virten.local --username root --password 'vmware'
vi-admin@vma:~> vifp addserver esx3.virten.local --username root --password 'vmware'
vi-admin@vma:~> vifp addserver vcsa.virten.local --username root --password 'vmware'

Используйте команду vifp listservers для того, чтобы посмотреть список сконфигурированных хостов для быстрого доступа:

vi-admin@vma:~> vifp listservers
esx1.virten.local ESXi
esx2.virten.local ESXi
esx3.virten.local ESXi
vcsa.virten.local vCenter

2. Используйте механизм vi-fastpass внутри скрипта. Это делается вот так (сценарий размещайте, где написано #do something):

#!/usr/bin/perl -w

use VMware::VIRuntime;
use VMware::VmaTargetLib;

my $service_content;
my @targets = VmaTargetLib::enumerate_targets();
foreach my $target(@targets) {
$target->login();
$service_content = Vim::get_service_content();
#do something
$target->logout();
}

Также примеры скриптов можно найти в папке /opt/vmware/vma/samples/perl:

vi-admin@vma:~> ls -l /opt/vmware/vma/samples/perl
total 24
-r--r--r-- 1 root root 2660 Jul 15 2013 README
-r-xr-xr-x 1 root root 9023 Jul 15 2013 bulkAddServers.pl
-r-xr-xr-x 1 root root 1282 Jul 15 2013 listTargets.pl
-r-xr-xr-x 1 root root 2452 Jul 15 2013 mcli.pl

Для примера также посмотрите скрипты отсюда (можете на них и поэкспериментировать, например, с esxcfg-perf.pl).

3. Создаем таску в кроне (cron job).

Синтаксис команды прост:

* * * * * command
| | | | |
| | | | ----- Day of week (0 - 7) (Sunday=0 or 7)
| | | ------- Month (1 - 12)
| | --------- Day of month (1 - 31)
| ----------- Hour (0 - 23)
------------- Minute (0 - 59)

Открываем крон в режиме редактирования:

vi-admin@vma:~> crontab -e

Нажмите <i>, чтобы перейти в режим вставки в crontab, после чего добавьте нужный путь к библиотеке и команду:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/vmware/vma/lib64:/opt/vmware/vma/lib
*/5 * * * * /home/vi-admin/scripts/esxi-perf.pl

Затем выходим из режима редактирования, нажав <ESC> : w q <ENTER>

Если при выполнении команды вы получаете вот такую ошибку:

vi-admin@vma:~> crontab -e
-bash: /usr/bin/crontab: Permission denied

То вам нужно предварительно выполнить sudo (юзер vi-admin в vMA 5.5 не имеет пермиссий на crontab):

vi-admin@vma:~> ll /usr/bin/crontab
-rwsr-x--- 1 root trusted 40432 Apr 2 2013 /usr/bin/crontab
vi-admin@vma:~> sudo chmod +rx /usr/bin/crontab
vi-admin@vma:~> ll /usr/bin/crontab
-rwsr-xr-x 1 root trusted 40432 Apr 2 2013 /usr/bin/crontab

4. Если крон-таска упадет, то вывод ошибок будет направляться сюда:

/var/mail/vi-admin

Вывод ошибки может быть таким:

Can’t load ‘/usr/lib/perl5/site_perl/5.10.0/libvmatargetlib_perl.so’ for module vmatargetlib_perl: libtypes.so: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/DynaLoader.pm line 203.
at /usr/lib/perl5/site_perl/5.10.0/VMware/VmaTargetLib.pm line 10
Compilation failed in require at /usr/lib/perl5/site_perl/5.10.0/VMware/VIFPLib.pm line 9.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.10.0/VMware/VIFPLib.pm line 9.
Compilation failed in require at /home/vi-admin/graphite/esxi-perf-graphite.pl line 5.
BEGIN failed–compilation aborted at /home/vi-admin/graphite/esxi-perf-graphite.pl line 5.

Это значит вы некорректно добавили путь к библиотеке (/opt/vmware/vma/lib64:/opt/vmware/vma/lib).

Если же вы получаете вот такую ошибку:

“Server version unavailable at ‘https://[host]:443/sdk/vimService.wsdl’ at /usr/lib/perl5/5.10.0/VMware/VICommon.pm line 545.”

Это из-за непрошедшей SSL-аутентификации. Если у вас нет валидных SSL-сертификатов, отключите авторизацию через SSL в вашем скрипте:

# Disable SSL Verification
export PERL_LWP_SSL_VERIFY_HOSTNAME=0

В блоге joshodgers.com появилось пять интересных статей о том, как правильно виртуализовать почтовый сервер Microsoft Exchange на платформе VMware vSphere.

Итак, что там интересного:

1. Part 1 – CPU Sizing.

Тут прелагается использовать утилиту Exchange 2013 Server Role Requirements Calculator v6.6 для определения требований к почтовому серверу:

2. Part 2 – vCPU Configurations.

В этой статье обсуждается необходимое число vCPU для виртуальной машины с Exchange.

Ничего необычного, в принципе, но стоит почитать.

3. Part 3 – Memory.

Тут обсуждается необходмый объем памяти. Не рекомендуется использовать Memory Overcommitment (то есть, часть ресурсов надо всегда держать свободными), а вот Memory Reservations предлагается устанавливать в 100% - таковы рекомендации для бизнес-критичного сервиса.

К выделенной памяти виртуальным машинам рекомендуется прибавлять как минимум 25% требуемой емкости памяти хоста ESXi. То есть, если у вас машина с 96 ГБ RAM, то хост должен иметь как минимум 128 ГБ физической памяти. Также рекомендуется сайзить машину с Exchange в пределах одного NUMA-узла.

4. Part 4 – DRS.

Тут основная рекомендация - держать машины с ролями MBX / MSR на одном хосте в целях быстродействия (средствами хост-групп), а также настроить их восстановление в случае сбоя также на один хост. Также уровень автоматизаци миграций ВМ в кластере рекомендуют выставить как "Fully Automated" (а Migration Threshold как 3).

5. Part 5 – High Availability (HA).

В этой части цикла описываются рекомендуемые настройки механизма VMware HA.

В этой статье, пожалуй, больше всего дается практических советов и рекомендаций по настройке VMware HA в кластере высокой доступности для виртуальных машин с Exchange на борту.

Компания Код Безопасности, выпускающая продукт vGate R2, который позволяет защитить виртуальную инфраструктуру предприятия от несанкционированного доступа, а также правильно настроить ее на базе политик, скоро проведен интересный и бесплатный вебинар "Основные особенности обеспечения безопасности платформ виртуализации VMware vSphere".

Данный вебинар будет интересен любому, кто когда-либо задумывался о защите виртуальной инфраструктуры VMware vSphere.

Вебинар пройдет: 24 декабря в 11:00 по московскому времени. Проводит: Иван Колегов, системный аналитик компании "Код Безопасности".

Мероприятие будет интересно руководителям ИБ-служб, а также специалистам, обеспечивающим безопасность дата-центров и защиту виртуальных инфраструктур.

В ходе вебинара вы узнаете:

• об архитектуре vGate и его компонентах;
• о правилах лицензирования продукта;
• о том, как быстро установить vGate и правильно его настроить;
• о том, как с его помощью обеспечить безопасность средств управления платформ виртуализации и виртуальных машин.

Продолжительность вебинара – 60 минут.

По окончании вебинара вы сможете задать докладчику вопросы в режиме чата и оставить заявки на получение демоверсии продукта и дополнительных материалов.

РЕГИСТРАЦИЯ на бесплатный вебинар

Для тех из вас, кто по каким-либо причинам еще не обновился на vSphere 5.5, полезная новость - вышло обновление VMware vSphere 5.1 Update 3 (ESXi и vCenter), которое уже доступно для загрузки. Новых возможностей не появилось, зато была добавлена поддержка новых гостевых ОС и исправлены некоторые значимые баги.

Итак, что нового в ESXi и vCenter 5.1 U3:

• Поддержка новых БД vCenter Server - теперь можно использовать Oracle 12c и Microsoft SQL Server 2014
• Поддержка новых браузеров для Web Client 5.1 Update 3. Теперь поддерживаются:
  • Internet Explorer 8 / 9 / 10/ 11
  • Firefox 31 / 32 / 33
  • Google Chrome 36 / 37
• Поддержка новых гостевых ОС. Полный список поддерживаемых ОС можно посмотреть тут.
• Множественные исправления ошибок. Полный список тут. Самое главное - пофикшен баг с некорректным бэкапом после увеличения дисков.

Ссылки на загрузку :

• VMware vCenter Server 5.1.0 Update 3
• VMware ESXi 5.1 Update 3

Кроме того, был также обновлен и кастомизированный образ для серверов HP. Его можно скачать по этой ссылке - ESXi 5.1 Update 3 HP Customized.

Новые возможности кастомизированного образа:

• Поддержка серверов Gen9 HP ProLiant
• Утилита HP CONREP Utility, которая позволяет сохранить аппаратную конфигурацию сервера и распространить ее на другие системы
• Поддержка Smart Array HBA mode
• Поддержка новых контроллеров HP Smart Array
• Поддержка новых HP Smart HBA
• Поддержка памяти DDR4
• Поддержка технологии SR-IOV (вот тут список поддерживаемых адаптеров и драйверов)

Для VMware vSphere 5.5 тоже на днях вышел небольшой багофикс.

Компания VMware выпустила еще один интересный документ, описывающий референсную архитектуру программно-определяемого датацентра (SDDC) - "Creating a VMware Software-Defined Data Center".

В данном документе на 29 страницах приводится пример создания корпоративной инфраструктуры на базе следующих продуктов:

• vCloud Suite Enterprise (подробнее тут)
• VMware vSphere
• VMware NSX (подробнее тут)
• VMware IT Business Management
• VMware vCenter Log Insight (подробнее тут)

Документ состоит из нескольких основных секций:

• Описание программных компонентов для построения SDDC-инфраструктуры
• Обзор референсной архитектуры
• Информация об оборудовании и аппаратных компонентах
• Детальная информация о компонентах Software-Defined Data Center
• Высокоуровневая конфигурация инфраструктуры SDDC

В рассматриваемой архитектуре есть три основных модуля:

• Management Cluster - основной кластер управления и мониторинга, в котором работают такие средства как vCenter, Log Insight и прочие. Состоит минимум из трех хост-серверов ESXi.
• Edge Cluster - отдельный кластер для управления сетевым взаимодействием. Он упрощает конфигурацию физической сети передачи данных путем создания абстракции физического сетевого стека в ИТ-инфраструктуре. Также содержит минимально 3 хоста.
• Payload Cluster - "рабочая лошадка" виртуальной инфраструктуры, кластер, где крутятся рабочие нагрузки. Может масштабироваться "подами" (pods) по мере роста потребностей предприятия.

В целом документ весьма интересный, так как в комплексе затрагивает управляющие компоненты виртуальной инфраструктуры и показывает работу средств управления большой виртуальной средой, а также то, каким образом эти средства решают возникающие в такой инфраструктуре проблемы.

Некоторое время назад мы писали заметку о том, "Почему снапшоты виртуальных машин в VMware vSphere - это плохо", да и вообще часто затрагиваем эту тему.

Ниже мы приведем еще один аргумент в пользу того, чтобы не создавать снапшоты виртуальных машин на постоянной основе (во временном их использовании нет ничего плохого).

Итак, в одной из статей мы писали про расширенную настройку VMFS Heap Size (размер кучи), которая косвенно определяет максимально доступный объем хранилищ на хосте.

Также мы писали о том, что параметр VMFS3.MaxHeapSizeMB еще в VMware vSphere 5.1 был увеличен до 640 МБ.

Однако есть и куча для механизма "Copy-on-Write" (COW), которая определяется расширенной настройкой COW.COWMaxHeapSizeMB - она ограничивает число одновременно запущенных на хосте виртуальных машин. Механизм COW работает на хосте, когда у машины есть снапшоты (дельта-диски).

По умолчанию это значение равно 192 МБ, но может быть увеличено до 256 МБ:

Также этот параметр можно узнать из командной строки:

~ # esxcfg-advcfg -g /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 192

И установить его в максимальное значение:

~ # esxcfg-advcfg -s 256 /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 256MB

Давайте посмотрим, как расходуется пространство этой кучи на хосте, в зависимости от параметров виртуальных машин на нем. Вот тут есть такая интересная формула:

X = (75 / 100 * COW_HEAP_SIZE) / ((B / (2 * 1048576) * 4 * S) * Y)

где:

X - это максимальное число запущенных виртуальных машин на хосте,
COW_HEAP_SIZE - размер кучи в байтах,
B - размер виртуального диска в байтах,
2 * 1048576 - это GDE Coverage (хз, что такое),
4 - это число байт на Root Entry,
S - число снапшотов каждого из виртуальных дисков,
Y - число дисков у машин.

Возьмем для примера машину с 5 дисками размером в 80 ГБ по 6 снапшотов у каждого при максимальном размере кучи в 256 МБ. Получим, что таких машин может быть запущено на хосте:

= (75 / 100 * 268435456) / ((85899345920 / (2 * 1048576) * 4 * 6) * 5)

Это примерно около 40 машин (всего лишь) - при максимально доступном размере кучи на VMware ESXi. Понятно дело, что мало где можно найти машины с 5 дисками, у каждого из которых по 6 снапшотов, но я видел подобные конфигурации пару раз.

Нетрудно понять, как в этой формуле влияют снапшоты на максимальное число запущенных виртуальных машин. Поэтому повторим еще раз: постоянные снапшоты - зло.

Многие из вас знают о продукте vGate R2 от компании Код Безопасности, который позволяет защитить виртуальную инфраструктуру предприятия от несанкционированного доступа, а также безопасно настроить ее на базе политик. Напомним, что vGate R2 есть как для VMware vSphere, так и для инфраструктуры Microsoft Hyper-V.

Тем из вас, кому приходится обрабатывать в своей компании персональные данные (ПДн), наверняка знаком приказ ФСТЭК номер 21 "Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных". На него ориентируются менеджеры физических и виртуальных инфраструктур при организации защиты датацентра, где присутствует обработка ПДн.

Надо сказать, что компания Код Безопасности обеспечивает исполнение этого приказа во всех аспектах, но нас больше интересует виртуальная среда. Итак, скачиваем вот этот документ с сайта Кода Безопасности.

Открываем его на первой вкладке и видим необходимые нам категории в столбце "vGate 2.5":

Очень удобно, что все требования разбиты по категориям, а также указано сразу какой уровень защищенности ПДн обеспечивает то или иное средство. Вот какие конкретно требования ФСТЭК по защите персональных данных позволяет выполнить vGate R2:

• Идентификация и аутентификация пользователей, являющихся работниками оператора
• Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных
• Управление идентификаторами, в том числе cоздание, присвоение, уничтожение идентификаторов
• Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
• Защита обратной связи при вводе аутентификационной информации
• Управление (заведение, активация, блокирование и уничтожение) учетными записями пользователей, в том числе внешних пользователей
• Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа
• Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами
• Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы
• Ограничение неуспешных попыток входа в информационную систему (доступа к информационной системе)
• Разрешение (запрет) действий пользователей, разрешенных до идентификации и аутентификации
• Поддержка и сохранение атрибутов безопасности (меток безопасности), связанных с информацией в процессе ее хранения и обработки
• Обеспечение доверенной загрузки средств вычислительной техники
• Управление запуском (обращениями) компонентов программного обеспечения, в том числе определение запускаемых компонентов, настройка параметров запуска компонентов, контроль за запуском компонентов программного обеспечения
• Определение событий безопасности, подлежащих регистрации, и сроков их хранения
• Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения
• Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти
• Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
• Защита информации о событиях безопасности
• Контроль работоспособности, параметров настройки и правильности функционирования программного обеспечения и средств защиты информации
• Контроль правил генерации и смены паролей пользователей, заведения и удаления учетных записей пользователей, реализации правил разграничения доступа, полномочий пользователей в информационной системе
• Контроль целостности программного обеспечения, включая программное обеспечение средств защиты информации
• Контроль целостности персональных данных, содержащихся в базах данных информационной системы
• Обеспечение возможности восстановления программного обеспечения, включая программное обеспечение средств защиты информации, при возникновении нештатных ситуаций
• Резервирование технических средств, программного обеспечения, каналов передачи информации, средств обеспечения функционирования информационной системы
• Идентификация и аутентификация субъектов доступа и объектов доступа в виртуальной инфраструктуре, в том числе администраторов управления средствами виртуализации
• Управление доступом субъектов доступа к объектам доступа в виртуальной инфраструктуре, в том числе внутри виртуальных машин
• Регистрация событий безопасности в виртуальной инфраструктуре
• Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по периметру виртуальной инфраструктуры
• Доверенная загрузка серверов виртуализации, виртуальной машины (контейнера), серверов управления виртуализацией
• Управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных
• Контроль целостности виртуальной инфраструктуры и ее конфигураций
• Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей
• Обеспечение доверенных канала, маршрута между администратором, пользователем и средствами защиты информации (функциями безопасности средств защиты информации)
• Обеспечение подлинности сетевых соединений (сеансов взаимодействия), в том числе для защиты от подмены сетевых устройств и сервисов
• Изоляция процессов (выполнение программ) в выделенной области памяти

Да да, все это умеет делать vGate R2. Для того, чтобы узнать о том, как именно он это делает, читайте наши статьи тут и тут.

Кстати, этот эксель-док очень интересен с точки зрения комплексной защиты персональных данных, обрабатываемых в ИТ-инфраструктуре. Посмотрите различные продукты, пощелкайте по вкладкам - там много интересного.

Демо-версию vGate для Hyper-V можно бесплатно скачать по этой ссылке, а для VMware vSphere - по этой.

Как многие из вас знают, у компании VMware есть бесплатный продукт VMware vSphere Hypervisor, который в народе называется VMware ESXi Free. Многие начинающие администраторы, услышав, что ESXi бесплатен, устанавливают его, но забывают накатить лицензию, которую надо скачивать с портала My VMware. Без этого бесплатный VMware ESXi будет работать в режиме пробной версии 60 дней...

Многие администраторы устанавливают VMware Tools с помощью vSphere Client, который предоставляет идущую в дистрибутиве версию этого пакета. Однако не все знают, что VMware Tools можно скачать по прямой ссылке из репозитория VMware, затем положить exe-файл на файловый сервер (если у вас гостевая ОС Windows) и запускать на всех виртуальных машинах.

Последняя версия тулзов всегда находится по этой ссылке:

http://packages.vmware.com/tools/esx/latest/index.html

Для Windows-машин она, соответственно, находится вот тут:

http://packages.vmware.com/tools/esx/latest/windows/index.html

Но эти пакеты доступны только для следующих версий гостевых ОС:

• Community ENTerprise Operating System (CentOS) - версии с 4.0 по 6.x
• Red Hat Enterprise Linux версии с 3.0 по 6.x
• SUSE Linux Enterprise Server версии 9 по 11
• SUSE Linux Enterprise Desktop версии 10 по 11
• Ubuntu Linux версии с 8.04 по 12.04

Надо отметить, что доступные в репозитории пакеты содержат компоненты VMware Tools, начиная еще с версий ESX 3.5. Но с версии vSphere 4.1 все они стали обратно совместимы - вы можете скачать последнее обновление VMware Tools и накатить его на любую версию vSphere 4.x или 5.x.

Это подтверждает и матрица совместимости продуктов VMware:

Кроме того, если в списке остутствуют необходимые ОС Linux, то можно воспользоваться пакетом Open VM Tools, которые являются открытой версией VMware Tools и рекомендованы к распространению вендорами платформ. Например, вот тут указано, как нужно ставить Open VM Tools в гостевых ОС RHEL 7.

Сами же репозитории находятся по этой ссылке:

http://packages.vmware.com/packages/index.html

Как установить IP-параметры HP iLO через консоль сервера VMware ESXi.

При развертывании инфраструктуры VMware vSphere на базе серверов HP всегда требуется задать параметры IP-идентификации для интерфейса удаленной консоли iLO. Обычно это делается в настройках сервера, но удобнее сделать это из консоли ESXi, если вы используете кастомизированную сборку ESXi под HP (а ее надо использовать, так как некоторые девайсы могут просто не работать, поскольку в стандартной сборке под них нет драйверов).

Для начала откроем на хосте ESXi доступ по SSH в разделе Security Profile, стартовав соответствующий сервис:

Заходим на хост по SSH и переходим в папку с утилитами HP:

cd /opt/hp/tools

Копируем настройки HP iLO в файл XML:

./hponcfg -w ilo.xml

Далее этот файл нам нужно отредактировать, для этого можно использовать WinSCP или Veeam FastSCP.

Копируем iLO.xml к себе локально:

Открываем его в текстовом редакторе и правим секции, помеченные красным:

<!-- HPONCFG VERSION = "4.0-13.0" -->
<!-- Generated 11/11/2014 23:37:47 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED VALUE = "N"/>
<DIR_LOCAL_USER_ACCT VALUE = "Y"/>
<DIR_SERVER_ADDRESS VALUE = ""/>
<DIR_SERVER_PORT VALUE = "636"/>
<DIR_OBJECT_DN VALUE = ""/>
<DIR_OBJECT_PASSWORD VALUE = ""/>
<DIR_USER_CONTEXT_1 VALUE = ""/>
<DIR_USER_CONTEXT_2 VALUE = ""/>
<DIR_USER_CONTEXT_3 VALUE = ""/>
</MOD_DIR_CONFIG>
</DIR_INFO>
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "100"/>
<FULL_DUPLEX VALUE = "N"/>
<IP_ADDRESS VALUE = "192.168.16.33"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.16.254"/>
<DNS_NAME VALUE = "ESX01-iLO"/>
<PRIM_DNS_SERVER value = "192.168.16.1"/>
<DHCP_ENABLE VALUE = "N"/>
<DOMAIN_NAME VALUE = "educ.local"/>
<DHCP_GATEWAY VALUE = "Y"/>
<DHCP_DNS_SERVER VALUE = "Y"/>
<DHCP_STATIC_ROUTE VALUE = "Y"/>
<DHCP_WINS_SERVER VALUE = "Y"/>
<REG_WINS_SERVER VALUE = "Y"/>
<PRIM_WINS_SERVER value = "0.0.0.0"/>
<STATIC_ROUTE_1 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_2 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_3 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
<USER_INFO MODE="write">
</USER_INFO>
</LOGIN>
</RIBCL>

Копируем измененный файл обратно на хост ESXi (предыдущий сохраните - просто переименуйте) и выполняем команду заливки конфигурации:

./hponcfg -f ILO.xml

Дождитесь успешного выполнения команды - и можно коннектиться к iLO через веб-браузер по новому адресу. Этот способ удобен тем, что можно не перезагружать сервер.

Многие пользователи VMware Virtual SAN (VSAN), когда проводят тест бэкапа одной виртуальной машины, замечают, что время резервного копирования этой ВМ существенно больше, чем таковое для машины, размещенной на дисковом массиве.

Дункан в своем блоге подробно разбирает эту проблему. Тут дело вот в чем - когда вы используете дисковый массив, то виртуальная машина "размазывается" по дискам RAID-группы, что позволяет читать одновременно с нескольких дисков. Это дает хорошую производительность операции резервного копирования для одной машины.

Кластер же VSAN работает немного по-другому. Это объектное хранилище, в котором виртуальный диск ВМ хранится на одном хосте и его реплика существует на втором. Кроме этого, есть кэш на SSD-диске (но его еще нужно "прогреть"). То есть выглядит все это следующим образом:

Соответственно, при бэкапе одной виртуальной машины данные читаются только с двух HDD-дисков, а не с нескольких как в традиционной архитектуре дисковых массивов, при этом сам кластер VSAN может состоять из нескольких хостов (до 32 узлов). То есть, это архитектурное ограничение.

Однако если мы будем делать одновременный бэкап нескольких виртуальных машин с хранилища Virtual SAN время этой операции уже будет сравнимо с дисковым массивом, поскольку будет задействовано сразу несколько дисков на каждом из хостов, плюс хорошо прогреется кэш. Поэтому проведение такого теста (ведь он ближе к реальным условиям) и было бы более показательным при сравнении Virtual SAN и традиционных хранилищ.

То же самое относится и к VDI-инфраструктуре на базе VSAN - многие пользователи отмечают, что первая фаза операции Recompose (когда создается реплика - полный клон ВМ) отрабатывает весьма медленно. Однако если вы делаете много таких операций - кэш прогревается, и одновременное создание нескольких клонов начинает работать заметно быстрее в расчете на одну машину.

Многие пользователи в целях безопасности хотят отключить использование USB-портов на хостах VMware ESXi - а то кто-нибудь зайдет в серверную комнату и утащит данные на диске.

К сожалению, на текущих версиях платформы VMware vSphere сделать этого нельзя. Можно, конечно, отключить USB Arbitrator service следующей командой (как написано вот тут):

/etc/init.d/usbarbitrator stop

Но это лишь отключит проброс USB-устройств в виртуальные машины, при этом само устройство (например,  /dev/usb0101) отключено не будет. Поэтому, тут остается два решения:

• Отключить USB-устройства в BIOS - но это поддерживают не все производители железа.
• Мониторить использование локальных USB-устройств и слать алерты менеджеру по ИБ.

Второй вариант можно реализовать с помощью продукта VMware vRealize Log Insight, который позволяет мониторить логи хостов ESXi и слать по ним алерты при их появлении и повторении. Вот, например, в выводе этого лога мы видим, что кто-то подключал USB-девайс к хосту:

Сопоставив время этих событий и время посещения конкретными людьми датацентра, мы поймем, кто пытался или сделал что-то нехорошее. Решение, конечно, не ахти, но какое уж есть.

На сайте компании VMware есть полезная утилита vSphere Replication Calculator, которая позволяет рассчитать целевые параметры репликации в зависимости от следующих факторов:

• Наличие у вас Network-based storage
• Число виртуальных машин и объем виртуальных дисков - как следствие размер реплицируемых данных (Size of dataset)
• Интенсивность изменения данных (Data change rate)
• Требования к контрольной точке восстановления (Recovery point objective, RPO)
• Имеющийся канал на резервную площадку (Link speed)

В качестве результата расчетов можно выбрать одно из трех представлений (все зависит от значения поля "Are you trying to solve..."):

• Необходимая минимальная пропускная способность сети на резервную площадку (recommended minimum throughput) с приемлемой latency (настраивается как входной параметр).
• Рекомендуемое минимальное время RPO в качестве политики, выражающей требования к контрольной точке восстановления.
• Максимальное число реплицируемых виртуальных машин при условии заданного объема изменяющихся данных.

Получившийся отчет можно сохранить в PDF.

Бывают такие ситуации, когда у вас в руках только мобильный телефон, с которого возникает необходимость перезагрузить виртуальную машину на хосте VMware ESXi. Например, у вас в инфраструктуре что-то случилось, но вы имеете доступ к ней через VPN со своего айфона.

Если у вас есть доступ по SSH, то проблему решить весьма просто, как это описано вот тут (а также в KB 1014165). Скачиваем бесплатное приложение Server Auditor по этой ссылке (если у вас андроид - то по этой).

Далее заходим на свой хост ESXi по SSH и выполняем команду:

esxcli vm process list

Будет выведен список всех процессов виртуальных машин, где нам нужно найти World ID нужной машины. Записываем или запоминаем его.

Далее убиваем виртуальную машину командой (вместо параметра force можно использовать hard и soft для выключения ВМ):

esxcli vm process kill -t force -w WorldID

Выглядит это примерно вот так:

Далее снова выполняем команду esxcli vm process list, чтобы убедиться, что виртуальная машина теперь выключена.

Теперь запоминаем VMID нашей виртуальной машины, который можно получить с помощью команды:

vim-cmd vmsvc/getallvms

Если помните часть имени ВМ, можно искать с помощью grep:

vim-cmd vmsvc/getallvms |grep <текст в имени ВМ>

Найдя VMID, проверяем дополнительно, что она выключена:

vim-cmd vmsvc/power.getstate <vmid>

Теперь включаем виртуальную машину:

vim-cmd vmsvc/power.on <vmid>

Вот и все, потом обязательно нужно проверить, что машина включилась, естественно - сначала в списке процессов, а потом пингом.

Как стало известно из VMware KB 2090639, в гипервизоре VMware vSphere 4.x и всех более поздних версий (включая vSphere 5.5) есть серьезный баг - оказывается, при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.

Напомним, что Changed Block Tracking - это техника, которая работает на уровне стека работы с хранилищами в модуле VMkernel и позволяет сторонним продуктам для резервного копирования вернуть список изменившихся блоков с момента последнего бэкапа. Технику CBT используют практически все решения для резервного копирования виртуальных машин, в частности Veeam Backup and Replication.

Сама же ошибка в VMware vSphere связана с тем, что функция QueryChangedDiskAreas, возвращающая информацию об изменившихся дисковых секторах, может выдавать некорректное или вообще пустое значение. Таким образом, если вы восстановите инкрементальный бэкап такой машины, то он работать не будет.

Еще раз отметим, что риску подвержены только те виртуальные машины, размер виртуальных дисков был увеличен до величины строго большей 128 ГБ (а также 256, 512 и т.п. - то есть "перешагнул" границу). Иными словами, если вы со 100 ГБ увеличили диск до 120 ГБ - ошибки не будет, а вот если со 120 ГБ до 130 ГБ - ошибка уже появится.

На данный момент исправления для этой проблемы, потенциально затрагивающей практически всех пользователей VMware vSphere (так как баг есть и в 4.x, и в 5.x), не существует. В качестве костыля можно отключить CBT на всех виртуальных машинах и включить его снова - тогда баг должен уйти.

Сделать это можно через скрипт PowerCLI.

Получаем список всех виртуальных машин с включенной CBT:

$vms=get-vm | ?{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

Создаем спецификацию для наложения нужной настройки (CBT - отключена):

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.ChangeTrackingEnabled = $false

Применяем спецификацию к каждой виртуальной машине, затем создаем и удаляем снапшот:

foreach($vm in $vms){
$vm.ExtensionData.ReconfigVM($spec)
$snap=$vm | New-Snapshot -Name 'Disable CBT'
$snap | Remove-Snapshot -confirm:$false}

Проверяем, остались ли машины со включенной CBT:

get-vm | ?{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

Для того, чтобы включить CBT обратно, в спецификации указываем $spec.ChangeTrackingEnabled = $true и повторяем процедуру.

Как всегда, первой подсуетилась компания Veeam и главный по продукту - Антон Гостев.

Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:

• Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
• Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).

Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.

Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.

Нажимаем Add Capacity:

Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):

Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):

Настройка Virtual Flash Host Swap

Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.

Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":

Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":

После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).

Настройка VMware Flash Read Cache (vFRC)

Напомним, что это кэш только на чтение данных, операции записи будут производиться на диск, минуя флэш-накопители. Соответственно, такой кэш улучшает производительность только операций чтения.

Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.

Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:

Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.

По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):

Чтобы понять, какие значения SSD-кэша можно и нужно выставлять для виртуальных машин, рекомендуется почитать документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5".

Ниже приведем ссылки на статьи VMware Knowledge Base (взято отсюда), где можно узнать о расположении и назначении файлов журнала (логов) для различных продуктов, включая компоненты решения VMware vSphere.

vSphere Suite

vCenter Server:

• Location of vCenter Server log files (1021804)
• Location of vCenter Inventory Service log files (2056632)
• Location of vSphere Profile-Driven Storage log files (2056646)
• Location of vCenter Single Sign-On log files for vCenter Server 5.1 and 5.5 (2033430)
• Collecting diagnostic information for the vSphere Client or VMware Infrastructure Client (1003687)
• Location of vSphere Web Client service logs (2004090)
• Locating logs for VMware vSphere Update Manager 5.0 (2038036)
  

ESX(i):

• Location of vSphere ESXi Dump Collector log files (2003277)
• Location of ESX 3.0-4.1 log files (1021800)
• Location of ESXi 3.5-4.1 log files (1021801)
• Location of ESXi 5.0 log files (2004201)
• Location of ESXi 5.1 and 5.5 log files (2032076)

vSphere Data Recovery:

• Location of VMware Data Recovery (VDR) log files (1022680)

vSphere Storage Appliance:

• Location of vSphere Storage Appliance log files (2003547)

Site Recovery Manager

• Location of Site Recovery Manager log files (1021802)

vCloud Suite

vCloud Director:

• Location of vCloud Director log files (2021435)
• Overview of Lab Manager log files (1011478)

vShield/vCloud Networking and Security (vCNS):

• Overview of vShield logs (1026255)
• Obtaining logs and information needed for VMware vShield products (2012760)

VMware vCloud Automation Center 6.x:

• Log locations in VMware vCloud 6.x Suite (2074803)

vCenter Orchestrator:

• Location of vCenter Orchestrator log files (1010956)

Desktop Computing

View and Horizon View:

• Location of VMware View log files (1027744)

Horizon Mirage (formerly Mirage):

• Location of VMware Horizon Mirage log files (2046069)

VMware Workstation:

• Collecting diagnostic information for VMware Workstation (1346)

Компания VMware выпустила обновление VMware Remote Console 7.0 (VMRC) в связи с тем, что компания Google окончательно отказалась от NPAPI (Netscape Plugin API) в Google Chrome, функции которого активно используются текущей версией VMRC.

Напомним, что VMRC вы можете запустить, когда вы хотите получить полноценный доступ к консоли виртуальной машины из vSphere Web Client:

Если раньше линк "Download VMRC" вел только на статью KB (картинка из Web Client для vCenter 5.5 Update 2b), то теперь он ведет на страницу загрузки новой версии VMRC.

Новая версия VMRC 7.0 получила больше функций и стала ближе к консоли, которая есть у C# клиента. Однако, по-прежнему, отсутствуют, например, функции "Reset" и "Power Off":

Прямо из VMRC можно подредактировать основные настройки виртуальной машины:

Доступные функции в новой версии консоли:

• Проброс мыши и клавиатуры
• Посыл Ctrl + Alt + Delete
• Полноэкранный режим
• Операции с питанием (софтовые)
• Проброс клиентских устройств, таких как CD-ROM, USB и Floppy
• Редактирование основных настроек ВМ

VMRC 7.0 доступна пока только для Windows, поэтому на маках придется пользоваться консолью HTML5, но работа по созданию VMRC для Mac OS уже идет.

Кстати, консоль к отдельной ВМ можно запустить командой CLI, зная логин и пароль к vCenter, а также MoRef виртуальной машины:

C:\Program Files (x86)\VMware\VMware Remote Console\vmrc.exe vmrc://root@<VC addr>/?moid=vm-37

Скачать VMware Remote Console 7.0 можно по этой ссылке.

На сайте проекта VMware Labs появилась интересная утилита ESXtopNGC Plugin, позволяющая получить функциональность консольного средства мониторинга производительности esxtop прямо в vSphere Web Client.

Возможности VMware ESXtopNGC Plugin:

• Отдельные вкладки для статистик процессора, памяти, сети и дисковой подсистемы.
• Гибкий вывод данных, в том числе в пакетном режиме.
• Удобный и гибкий выбор необходимых счетчиков.
• Полнофункциональное представление статистик с возможностью сортировки колонок, раскрытия строчек и т.п.
• Настраиваемый период обновления данных.
• Статистики по виртуальным машинам (VM-only stats).
• Встроенные тултипы с описаниями назначений счетчиков.

Плагин ESXtopNGC на данный момент работает только с виртуальным модулем vCenter Server Appliance (vCSA) 5.5 или более поздних версий.

Для установки плагина загрузите его в одну из директорий на vCSA и выполните там команду:

unzip ESXtopNGCPlugin.zip -d /usr/lib/vmware-vsphere-client/plugin-packages/esxtop-plugin
/etc/init.d/vsphere-client restart

После этого в vSphere Web Client на вкладке "Monitor" для хостов появится представление "Top".

Скачать VMware ESXtopNGC Plugin можно по этой ссылке.

Четыре с половиной года назад мы писали про то, что у технологии Transparent Page Sharing (TPS), которая по-умолчанию используется в VMware vSphere, нет будущего. Напомним, что TPS - это механизм поиска и удаления дубликатов страниц памяти в целях экономии физического пространства RAM (вместо самой дублирующейся страницы хранится ссылка на нее).

Технолония потеряла актуальность, когда вовсю стали применяться большие страницы памяти (Large Memory Pages), для которых размер страницы равен 2 МБ, а значит вероятность появления двух полностью одинаковых страниц очень низка.

Ну вот и пришло время эту технологию отключать. На днях компания VMware выпустила статью базы знаний "Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing", в которой заявляется о том, что в будущих релизах платформы виртуализации VMware vSphere функции TPS будут по умолчанию отключены (хотя и доступны).

Это во многом связано с тем, что TPS (помимо негативного влияния на производительность хоста) - это еще и потенциальный источник проблем, связанных с неавторизованным доступом к данным оперативной памяти. Эти моменты основаны на аналитическом исследовании, выводы из которого опубликованы в статье базы знаний "Additional Transparent Page Sharing management capabilities in ESXi 5.5 patch October 16, 2014 and ESXi 5.1 and 5.0 patches in Q4, 2014 (2091682)".

Вот когда TPS будет отключен в VMware vSphere:

• ESXi 5.5 Update release – Q1 2015
• ESXi 5.1 Update release – Q4 2014
• ESXi 5.0 Update release – Q1 2015
• VMware ESX 6.x и более поздние версии

Более подробно о проблемах с TPS написано вот в этой статье на блогах VMware.

Если же вы хотите отключить этот механизм уже прямо сейчас, то нужно сделать следующее:

1. Залогиниться на ESX\ESXi или vCenter Server через vSphere Client.
2. Выбрать нужный хост и зайти на вкладку Configuration, затем перейти в Advanced Settings в секции Software.
3. Выбираем раздел Mem и в нем устанавливаем значение параметра Mem.ShareScanGHz в 0.

После патча и обновлений ESXi механизм TPS можно будет включить следующим образом (Advanced Settings в секции Software):

• Параметр Mem.ShareForceSalting (включение TPS на уровне всего хоста ESXi). Если значение стоит 0 - то значит TPS по-прежнему работает на хосте, если 1 - механизм отключен.
• Параметр sched.mem.pshare.salt (ставится на уровне ВМ) позволяет включать/отключать TPS для отдельных виртуальных машин (например, старые Windows или линуксы - для них можно было бы включить). Когда параметр ShareForceSalting установлен в значение 1, то для нуждающихся в TPS машин в их Advanced Configuration нужно установить одинаковые значения "соли". Без этого TPS не работает - соответственно, он отключен.

Оказывается, пару месяцев назад, еще до проходящего сейчас в Барселоне VMworld Europe 2014, компания VMware сделала анонс VMware Site Recovery Manager 5.8 - средства создания катастрофоустойчивой архитектуры виртуального датацентра. Но на днях была обновлена vSphere Replication до версии 5.6, где появилась возможность проводить безопасную репликацию виртуальных машин в облако VMware vCloud Air, поэтому новость про SRM 5.8 сейчас будет очень кстати.

Напомним, что прошлую мажорную версию VMware SRM 5.5 компания VMware выпустила больше года назад.

Новые возможности VMware SRM 5.8:

• Наконец-то SRM полностью поддерживает vSphere Web Client (ранее он был доступен только для "толстого" клиента).

Интерфейс полнофункциональный. Вот, например, автоматическое создание реверсного мапинга на резервной площадке:

• Теперь в рамках создания плана аварийного восстановления можно мапить не только отдельные IP-адреса машин (что неудобно при массовом мапинге), но и целые подсети (IP customisation plans).

• Новая версия vSphere Replication обеспечивает возможность проводить безопасную репликацию виртуальных машин в облако VMware vCloud Air.
• vSphere replication calculator - возможность посчитать, какой канал вам потребуется для репликации нужного числа виртуальных машин.
• Enhanced reporting – в новой версии vSphere Replication появилось новое представление reporting dashboard, которое представляет детальную информацию об использовании vSphere Replication.
• Появился новый плагин VMware Orchestrator Plugin for SRM для автоматизации операций SRM (это необходимо для нестандартных и комплексных сценариев).
• SRM теперь может использовать встроенную базу данных vPostgres для быстрого развертывания.
• Полная поддержка VSAN и vSphere Storage Appliance (VSA).
• Интегрированная Windows-аутентификация при использовании БД Microsoft SQL Server (подробнее тут).
• Поддержка интеграции с vCloud Automation Center (vCAC - сейчас этот продукт называется vRealize Automation) - появились средства самообслуживания пользователей.

Скачать VMware Site Recovery Manager 5.8 можно по этой ссылке. Документация доступна тут, а вот тут - презентация о новых фичах с VMworld.